1. Field of Invention
Embodiments of the invention relate, in general, to database management. More specifically, embodiments of the invention relate to updating immutable bookmarks in a database.
2. Description of the Background Art
In relational databases, such as an Oracle relational database, certain data type codes are used internally by the database. One data type code is a large object or LOB, which may contain binary data comprising, by way of example, an image or a sound file. In other instances, the LOB may contain character data comprising an Extensible Markup Language (XML) document. LOBs are often stored in a database in multiple blocks of data, where each block is of database block size that may range from 2K to 32K in size. A LOB size can be as large as a few terabytes.
LOBs present unique handling problems because of their size. One such problem occurs when the LOB needs to be updated to add or delete data. Often, the update requires rewriting the entire LOB, which can span several database blocks depending on the size of the update. To avoid this time and resource consuming task, many relational database management systems merely append interim updates to a separate file and then from time to time perform a LOB reorganization to rewrite the LOB to remove any holes and obsolete data and to insert new additions.
As databases grow ever larger, a bookmark is a helpful user feature that enables a user to reach a specific location within the database quickly and with a minimum of effort. A bookmark is a marker that points to specified location in a designated LOB. When a user invokes the bookmark, the relational database management system returns the specified location.
To illustrate the concept of the bookmark, consider a database containing many LOBs each containing a book. Each LOB can range in size from a few bytes to a few terabytes, depending on the size of the book. A user may add a bookmark to the database so they can return to the start of a particular chapter or page without having to search the entire database for the starting location each time the user wants to access the starting location. Typically, because the type of data at the bookmarked location is not available to or known by the database management system, the bookmark is associated with a hard offset relative to the start of the LOB.
If an update to the LOB were to occur, such as if the preceding chapter were updated by adding (or deleting) a character or a page, the location of the bookmarked scene will start at a different offset. Unfortunately, when the LOB is reorganized, the bookmark offset is not translated to match the offset in the LOB where the particular chapter that was bookmarked by the user begins after the LOB is rewritten. Thus, after a database reorganization, it is common with prior database systems for a user to receive an incorrect offset since the bookmark is no longer correctly mapped to the desired content. Clearly, what is needed is a mechanism that will automatically calculate a new offset for the bookmark so that the user is able to correct access a bookmarked starting location after a database reorganization.